FHIR © HL7.org  |  Server Home  |  FHIR Server FHIR Server 3.4.11  |  FHIR Version n/a  User: [n/a]

Resource OperationDefinition/FHIR Server from package hl7.fhir.us.bulkdata#0.1.0 (62 ms)

Package hl7.fhir.us.bulkdata
Type OperationDefinition
Id Id
FHIR Version R4
Source http://hl7.org/fhir/us/bulkdata/http://hl7.org/fhir/us/bulkdata/2019May/OperationDefinition-group-export.html
Url http://hl7.org/fhir/us/bulkdata/OperationDefinition/group-export
Version 1.0.0
Status active
Date 2019-02-15T00:00:00+11:00
Name GroupLevelExport
Title FHIR Bulk Data Export (Flat FHIR) - System Level Export
Experimental False
Realm us
Authority hl7
Description FHIR Operation to obtain data on all patients listed in a single FHIR Group Resource. If a FHIR server supports Group-level data export, it SHOULD support reading and searching for Group resource. This enables clients to discover available groups based on stable characteristics such as Group.identifier. Note: How these groups are defined is implementation specific for each FHIR system. For example, a payer may send a healthcare institution a roster file that can be imported into their EHR to create or update a FHIR group. Group membership could be based upon explicit attributes of the patient, such as: age, sex or a particular condition such as PTSD or Chronic Opioid use, or on more complex attributes, such as a recent inpatient discharge or membership in the population used to calculate a quality measure. FHIR-based group management is out of scope for the current version of this implementation guide
Type false
Kind operation

Resources that use this resource

No resources found


Resources that this resource uses

No resources found



Narrative

Note: links and images are rebased to the (stated) source

GroupLevelExport

OPERATION: GroupLevelExport

The official URL for this operation definition is:

http://hl7.org/fhir/us/bulkdata/OperationDefinition/group-export

FHIR Operation to obtain data on all patients listed in a single FHIR Group Resource. If a FHIR server supports Group-level data export, it SHOULD support reading and searching for Group resource. This enables clients to discover available groups based on stable characteristics such as Group.identifier. Note: How these groups are defined is implementation specific for each FHIR system. For example, a payer may send a healthcare institution a roster file that can be imported into their EHR to create or update a FHIR group. Group membership could be based upon explicit attributes of the patient, such as: age, sex or a particular condition such as PTSD or Chronic Opioid use, or on more complex attributes, such as a recent inpatient discharge or membership in the population used to calculate a quality measure. FHIR-based group management is out of scope for the current version of this implementation guide

URL: [base]/Group/[id]/$$export

Parameters

UseNameCardinalityTypeBindingDocumentation
OUT_outputFormat0..1string

The format for the requested bulk data files to be generated. Servers MUST support Newline Delimited JSON, but MAY choose to support additional output formats. Servers MUST accept the full content type of application/fhir+ndjson as well as the abbreviated representations application/ndjson and ndjson. Defaults to application/fhir+ndjson

IN_since0..1instant

Resources updated after this period will be included in the response

OUT_type0..1string

A string of comma-delimited FHIR resource types. Only resources of the specified resource types(s) SHOULD be included in the response. If this parameter is omitted, the server SHOULD return all supported resources within the scope of the client authorization. For non-system-level requests, the Patient Compartment SHOULD be used as a point of reference for recommended resources to be returned as well as other resources outside of the patient compartment that are helpful in interpreting the patient data such as Organization and Practitioner. Resource references MAY be relative URIs with the format <resource type>/<id>, or absolute URIs with the same structure rooted in the base URI for the server from which the export was performed. References will be resolved looking for a resource with the specified type and id within the file set. Note: Implementations MAY limit the resources returned to specific subsets of FHIR, such as those defined in the Argonaut Implementation Guide


Source

{
  "resourceType" : "OperationDefinition",
  "id" : "group-export",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>GroupLevelExport</h2><p>OPERATION: GroupLevelExport</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/us/bulkdata/OperationDefinition/group-export</pre><div><p>FHIR Operation to obtain data on all patients listed in a single FHIR Group Resource. If a FHIR server supports Group-level data export, it SHOULD support reading and searching for Group resource. This enables clients to discover available groups based on stable characteristics such as Group.identifier. Note: How these groups are defined is implementation specific for each FHIR system. For example, a payer may send a healthcare institution a roster file that can be imported into their EHR to create or update a FHIR group. Group membership could be based upon explicit attributes of the patient, such as: age, sex or a particular condition such as PTSD or Chronic Opioid use, or on more complex attributes, such as a recent inpatient discharge or membership in the population used to calculate a quality measure. FHIR-based group management is out of scope for the current version of this implementation guide</p>\n</div><p>URL: [base]/Group/[id]/$$export</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>OUT</td><td>_outputFormat</td><td>0..1</td><td><a href=\"http://hl7.org/fhir/STU3/datatypes.html#string\">string</a></td><td/><td><div><p>The format for the requested bulk data files to be generated. Servers MUST support Newline Delimited JSON, but MAY choose to support additional output formats. Servers MUST accept the full content type of application/fhir+ndjson as well as the abbreviated representations application/ndjson and ndjson. Defaults to application/fhir+ndjson</p>\n</div></td></tr><tr><td>IN</td><td>_since</td><td>0..1</td><td><a href=\"http://hl7.org/fhir/STU3/datatypes.html#instant\">instant</a></td><td/><td><div><p>Resources updated after this period will be included in the response</p>\n</div></td></tr><tr><td>OUT</td><td>_type</td><td>0..1</td><td><a href=\"http://hl7.org/fhir/STU3/datatypes.html#string\">string</a></td><td/><td><div><p>A string of comma-delimited FHIR resource types. Only resources of the specified resource types(s) SHOULD be included in the response. If this parameter is omitted, the server SHOULD return all supported resources within the scope of the client authorization. For non-system-level requests, the Patient Compartment SHOULD be used as a point of reference for recommended resources to be returned as well as other resources outside of the patient compartment that are helpful in interpreting the patient data such as Organization and Practitioner. Resource references MAY be relative URIs with the format &lt;resource type&gt;/&lt;id&gt;, or absolute URIs with the same structure rooted in the base URI for the server from which the export was performed. References will be resolved looking for a resource with the specified type and id within the file set. Note: Implementations MAY limit the resources returned to specific subsets of FHIR, such as those defined in the Argonaut Implementation Guide</p>\n</div></td></tr></table></div>"
  },
  "url" : "http://hl7.org/fhir/us/bulkdata/OperationDefinition/group-export",
  "version" : "1.0.0",
  "name" : "GroupLevelExport",
  "title" : "FHIR Bulk Data Export (Flat FHIR) - System Level Export",
  "status" : "active",
  "kind" : "operation",
  "date" : "2019-02-15T00:00:00+11:00",
  "publisher" : "SMART Health IT",
  "contact" : [
    {
      "name" : "Ricky Sahu",
      "telecom" : [
        {
          "system" : "email",
          "value" : "ricky@1up.health"
        }
      ]
    },
    {
      "name" : "Dan Gottlieb",
      "telecom" : [
        {
          "system" : "email",
          "value" : "daniel.gottlieb@childrens.harvard.edu"
        }
      ]
    },
    {
      "name" : "Josh Mandel",
      "telecom" : [
        {
          "system" : "email",
          "value" : "joshua.mandel@childrens.harvard.edu"
        }
      ]
    },
    {
      "name" : "Vlad Ignatov",
      "telecom" : [
        {
          "system" : "email",
          "value" : "Vladimir.Ignatov@childrens.harvard.edu"
        }
      ]
    }
  ],
  "description" : "FHIR Operation to obtain data on all patients listed in a single FHIR Group Resource. If a FHIR server supports Group-level data export, it SHOULD support reading and searching for Group resource. This enables clients to discover available groups based on stable characteristics such as Group.identifier. Note: How these groups are defined is implementation specific for each FHIR system. For example, a payer may send a healthcare institution a roster file that can be imported into their EHR to create or update a FHIR group. Group membership could be based upon explicit attributes of the patient, such as: age, sex or a particular condition such as PTSD or Chronic Opioid use, or on more complex attributes, such as a recent inpatient discharge or membership in the population used to calculate a quality measure. FHIR-based group management is out of scope for the current version of this implementation guide",
  "code" : "$export",
  "resource" : [
    "Group"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "_outputFormat",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "The format for the requested bulk data files to be generated. Servers MUST support Newline Delimited JSON, but MAY choose to support additional output formats. Servers MUST accept the full content type of application/fhir+ndjson as well as the abbreviated representations application/ndjson and ndjson. Defaults to application/fhir+ndjson",
      "type" : "string"
    },
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Resources updated after this period will be included in the response",
      "type" : "instant"
    },
    {
      "name" : "_type",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A string of comma-delimited FHIR resource types. Only resources of the specified resource types(s) SHOULD be included in the response. If this parameter is omitted, the server SHOULD return all supported resources within the scope of the client authorization. For non-system-level requests, the Patient Compartment SHOULD be used as a point of reference for recommended resources to be returned as well as other resources outside of the patient compartment that are helpful in interpreting the patient data such as Organization and Practitioner. Resource references MAY be relative URIs with the format <resource type>/<id>, or absolute URIs with the same structure rooted in the base URI for the server from which the export was performed. References will be resolved looking for a resource with the specified type and id within the file set. Note: Implementations MAY limit the resources returned to specific subsets of FHIR, such as those defined in the Argonaut Implementation Guide",
      "type" : "string"
    }
  ]
}

XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.